Virtual prototyping solutions can greatly accelerate product development. Obviously, the more accurately a solution simulates “reality”, the more confidence one can have in that solution. On the other hand, though, the most useful simulation is typically the one that not only simulates reality faithfully, but also takes the fewest resources to do so.
Whereas reality is continuous in nature, computer simulations are forced to approximate the continuity by acting upon and examining and/or evaluating the simulation model only at discrete points in time. The greater the frequency at which the simulation model is examined, the more accurate is the simulation, since continuity is more closely approached. Thus, conventionally, simulations are designed such that the evaluation rate is high enough to sufficiently approximate reality (i.e., with acceptable error and without noticeable jumps in display), but not so fast that the computer's resources are completely exhausted.
The evaluation rate required depends largely upon the rate at which the simulated events would occur in reality. For example, if modeling the fast-moving parts within an engine, the evaluation rate should be relatively high. On the other hand, modeling the slow buildup of heat within the engine could be carried out at a much slower rate. Furthermore, where visual interaction is important, evaluation for display should be at a relatively high rate if the sensation of interactivity is to be provided to the user.
Since different aspects of a simulation occur with varying evaluation rate requirements, it would be preferable if each aspect executed at a rate most suitable to it. Unfortunately, conventional simulations force the entire simulation to execute at a common frequency. The common frequency is generally faster than required for some aspects of the simulation and perhaps slower than ideally required for other aspects of the simulation. For example, if the calculations of engine heat buildup could only be performed at once or twice a second due to the complexity of the calculations, the calculation of engine part positions could only be performed one or twice a second as well, even though it would be a much simpler calculation. Furthermore, visualization of movement around the engine would be seriously hampered, with position updates at only the once or twice per second rate.
A typical solution to the evaluation rate problem discussed above is to perform the simulation in batch, allowing the user to inspect the results in detail once the simulation is completed. A disadvantage of this approach, however, is that the simulation cannot be interactive.